Skip to content

Conversation

@tstellar
Copy link
Collaborator

Currently if you want to do a distribution build (i.e. using LLVM_DISTIRIBUTION_COMPONENTS) with a bolt-optimized clang, then you need to pass two separate targets to ninja like this:

ninja -C build clang-bolt distribiution

This patch simplifies this workflow so that you can do a distribution build with a bolt-optimized build with just a single target:

ninja -C build distribution

…ilds

Currently if you want to do a distribution build (i.e. using
LLVM_DISTIRIBUTION_COMPONENTS) with a bolt-optimized clang, then
you need to pass two separate targets to ninja like this:

ninja -C build clang-bolt distribiution

This patch simplifies this workflow so that you can do a
distribution build with a bolt-optimized build with just a single target:

ninja -C build distribution
@llvmbot llvmbot added the cmake Build system in general and CMake in particular label Nov 26, 2024
@petrhosek
Copy link
Member

Could we also gate this on CLANG_BOLT?

@tstellar
Copy link
Collaborator Author

Could we also gate this on CLANG_BOLT?

Is that redundant with the check for the clang-bolt target?

@tstellar
Copy link
Collaborator Author

I noticed this wasn't working for the install targets, so I had to add clang-bolt as a dependency to the install targets too.

I wonder if would be better to have the install targets depend on the distribution target instead.

@tstellar
Copy link
Collaborator Author

As I look into this more, it's not strictly a problem with distribution builds. Just enabling bolt and running ninja install-clang does not give you a bolt optimized clang. I'm going to try to do a more generic patch.

@aaupov
Copy link
Contributor

aaupov commented Nov 27, 2024

As I look into this more, it's not strictly a problem with distribution builds. Just enabling bolt and running ninja install-clang does not give you a bolt optimized clang.

Right, for that matter, it's not triggered by ninja clang as well. There's a problem that clang-bolt depends on clang target, so clang-bolt can't be a provider for it. In theory we could decouple targets: if CLANG_BOLT is provided, pre-BOLT clang target could be called differently, and clang-bolt target could be the provider for clang. But I thought it would be too ambitious for me to change how clang is built, which is why clang-bolt is "on the side".

@tstellar
Copy link
Collaborator Author

Right, for that matter, it's not triggered by ninja clang as well. There's a problem that clang-bolt depends on clang target, so clang-bolt can't be a provider for it. In theory we could decouple targets: if CLANG_BOLT is provided, pre-BOLT clang target could be called differently, and clang-bolt target could be the provider for clang. But I thought it would be too ambitious for me to change how clang is built, which is why clang-bolt is "on the side".

OK, I was thinking of doing something like add_dependencies(install-clang clang-bolt) but maybe it would make more sense for me to rewrite the clang target to do the bolt optimization.

@tstellar
Copy link
Collaborator Author

Closing this in favor of #119896.

@tstellar tstellar closed this Dec 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cmake Build system in general and CMake in particular

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants